We already have a demowarp feature. Could you try to use this instead?

We already have a demowarp feature. Could you try to use this instead?

Means, instead of using G_DemoGotoNextLevel, use crispy->demowarp in key_nextlevel handling?

That was my initial idea, yes. But this won't work because we cannot know what the next level will be (player may use regular or secret exit). Just scrap my idea.

Ah, got it. Yeah, we just running tics here as fast as possible, not indicating "go to this/that map" and stopping "full speed" right before player spawning in P_SpawnPlayer.

Guess, it's your review-turn now, I have nothing to add technically, except few thoughts:

• Keys are working in demo loop. Could be useful for testing, or... Or is it a bad idea?
• No smooth demo bar while jumping. Which is good, because this making jumping as fast as it gets. And hey, demo bar is not drawing on top of wipes.

Small problem, not exactly related to this PR: framerate is forcefully uncapped after using -warp in demo playing, but crispy->vsync remains untouched.

To fix framerate capping issue, we have to extend this condition:

// Turn on vsync if we aren't in a -timedemo
if ((!singletics && mode.refresh_rate > 0) || demowarp)
                                                ^^^^

Since demo warp is using singletics, which, in return, preventing vsync flag to be accounted. But this way demowarp must be externalized to upper level code, and the question is - where exactlly? Should it be i_video.h or extern int demowarp right in SetVideoMode?

I don't think this will link with the non-Doom games if you introduce demowarp as only an extern in the i_video.c context. You'll wither need a demowarp instantiation in each game, or you instantiate it in i_video.c itself.

Pardon me, it's far simpler as demowarp is a part of crispy_t structure. This will fix capping issue without any externals:

    // Turn on vsync if we aren't in a -timedemo
    if ((!singletics && mode.refresh_rate > 0) || crispy->demowarp)
                                                  ^^^^^^^^^^^^^^^^

We can't move it to condition below since !singletics is doing it's job.

Well then.

Please put extern in a header where it's also visible to the actual declaration. This helps the compiler catch bugs. The check-extern.sh script checks this. It's enabled in CI for Chocolate but not for Crispy.

@turol, understood for future, thanks.

Thanks for approval! Can we merge it now? On next PR I would like to implement IDCLEV'ing to any levels, not just next ones while demo playback, it's fairly simple (JNechaevsky/international-doom@faeb5a9).

For almost a week I was wondering what else can be done regarding demo playback, but no, nothing, zero ideas. Looks likes current features covers all possible needs, at least for simple wathching.

So far, info for changelog. Please correct my wording if needed:

• If vsync is active, framerate no longer forcefully uncapped after using demo warp (i.e. -playdemo demo.lmp -warp xx)
• Improved Crispy shortcut keys behavior while demo playback:
  • Restart level/demo: now restart demo but keeps it playing.
  • Go to next level: now warping to next level and keeps demo playing.

Thanks for approval! Can we merge it now?

That's what "aprroval" means, right? 😉

That's what "aprroval" means, right? 😉

Nothing can do with myself, I have a huge fondness for subordination when changing code in Crispy. ☺️